# HTB — **Expressway** — Full writeup
**Target:** 10.10.11.87
**Author:** Mrx0rd
**Date:** 2025-09-22
---
# Summary
Expressway is a small target with a few interesting UDP services. The initial surface revealed TFTP (69) and IKE (500) open/accessible — the latter exposing an IKEv1 Aggressive Mode handshake which allowed offline cracking of a pre-shared key (PSK). Using the recovered PSK we authenticated via SSH as ike, enumerated the filesystem, and then escalated to root using a public PoC for CVE-2025-32463 (sudo chroot "chwoot").
High-level steps:
1. Recon — UDP Nmap
2. IKE enumeration with ike-scan (Aggressive Mode)
3. Extract IKE PSK parameters and crack PSK with psk-crack
4. SSH as ike
5. Local enumeration (linpeas) -> identify CVE PoC
6. Run PoC (sudo chroot exploit) -> root
---
# 1) Recon
Command used:
sudo nmap -sU -p 68,69,500 10.10.11.87 |
Result (relevant lines):
PORT STATE SERVICE |
Notes:
- Port 500 (ISAKMP / IKE) was the highest-value target because IKE Aggressive Mode can leak information useful for offline PSK cracking.
- TFTP on 69 is worth probing for config/backups but the winning vector here came from IKE.
---
# 2) IKE enumeration (ike-scan)
I used ike-scan to probe port 500. Important findings:
sudo ike-scan -M -A 10.10.11.87 |
Output (trimmed):
10.10.11.87 Aggressive Mode Handshake returned |
Why this matters:
- Aggressive Mode returned an identity (`ike@expressway.htb`) and handshake material. Aggressive Mode is _insecure_ in that it allows offline verification attempts of the PSK; with the handshake material we can try dictionary/brute-force attacks offline.
---
# 3) Extracting the IKE PSK parameters and cracking
I next retrieved the full IKE PSK parameter blob with ike-scan --pskcrack (this prints the g_xr:...:hash_r blob which tools like psk-crack and hashcat can use).
Command used:
sudo ike-scan -A --pskcrack 10.10.11.87 > ike_psk_blob.txt |
The output contained a single long line labeled IKE PSK parameters (...) which I saved into ike.hash.
I then used psk-crack (bundled with ike-scan on many Kali installs) to perform a dictionary attack against that blob.
sudo psk-crack -d /usr/share/wordlists/rockyou.txt ike.hash |
psk-crack returned a matching PSK. With that PSK I tested connectivity to the host and successfully authenticated:
sudo ssh ike@10.10.11.87 |
On the box the user ike had UID/GID 1001 and was part of group proxy.
ike@expressway:~$ id |
Notes & tips:
- `psk-crack` is convenient for small-to-medium wordlists. For large-scale cracking prefer converting the blob to hashcat format and use `hashcat -m 5400` with GPU.
- Always try targeted wordlists first (service/host names, vendor names, default passwords) before huge lists to save time.
---
# 4) Initial post-auth enumeration
I ran linpeas which flagged a potentially interesting path under /tmp with a CVE PoC:
/tmp/qwe/10.10.16.38/CVE-2025-32463_chwoot |
That directory contained a publicly available PoC shell script sudo-chwoot.sh (and/or a related exploit script ex.sh / sudo-chwoot), which targets CVE-2025-32463 (a sudo chroot vulnerability allowing local privilege escalation via the --chroot option).
I verified the PoC repository and its contents (PoC publicly available on GitHub). The PoC essentially abuses sudo chroot handling to cause sudo to use an attacker-controlled /etc/nsswitch.conf (and/or library loading behavior) from a chrooted directory, allowing execution of arbitrary code as root.
---
# 5) Privilege escalation (CVE-2025-32463)
I followed the PoC pattern present on the machine. In short:
1. Prepare an attacker-controlled chroot directory that contains a malicious nsswitch.conf or other required files and a small payload/binary.
2. Trigger sudo --chroot (or the PoC script which uses sudo -R or similar) to make sudo load resources from the attacker-controlled directory as root.
3. Result: arbitrary code executed as root.
On this box, the supplied PoC was runnable directly. Example run (as ike):
ike@expressway:~$ cd /tmp/qwe/10.10.16.38/CVE-2025-32463_chwoot |
After executing the PoC script, the shell escalated to root and root.txt was readable.
---
# 6) Post-exploitation notes
Once root, standard follow-ups apply:
- Capture system info (`uname -a`, `/etc/os-release`), check sudo version (`sudo --version`) to document the vulnerable version range.
- Look for persisted credentials, SSH keys, misconfigurations, and lateral movement artifacts.
- Clean up if this were a real-assessment and you had permission; on HTB, just documenting is fine.
---
# 7) Mitigations & Remediation
To mitigate CVE-2025-32463 and similar issues:
- **Patch sudo**: upgrade to `sudo >= 1.9.17p1` which fixes the chroot handling bug.
- **Avoid exposing IKE Aggressive Mode**: reconfigure VPN endpoints to disable Aggressive Mode (use Main Mode) and prefer strong authentication (certificates) over weak PSKs.
- **Harden TFTP**: restrict TFTP access, require strong authentication for configuration retrieval, and avoid placing secrets in public TFTP locations.
- **Harden PSK usage**: if PSKs must be used, ensure they are long, random, and rotated; prefer certificate-based authentication when possible.
---
# 8) References
(For offline investigation and verification)
- Public PoC repo for CVE-2025-32463 (example): `pr0v3rbs/CVE-2025-32463_chwoot` on GitHub
- NIST NVD entry for CVE-2025-32463
- Public PoC mirrors / write-ups (several GitHub repos and vendor advisories)
---
# Appendix — useful commands used
# Recon |
---
